The present invention relates to determining the status of a device through use of a publisher/subscriber (pub/sub) interface.
Publish/subscribe data processing systems have become very popular as a way of distributing data messages. Publishers are not concerned with where their publications are going, and subscribers are not interested in where the messages they receive have come from. Instead, a message broker typically assures the integrity of the message source, and manages the distribution of the message according to the subscriptions registered in the broker.
Publishers and subscribers may interact with a network of brokers, each of which propagates subscriptions and forwards publications to other brokers within the network. When the term “broker” is used, it should be taken as encompassing a single broker or multiple brokers working together in a network.
FIG. 1 illustrates a typical publish/subscribe data processing system according to the prior art. A message broker 15 has an input mechanism 20 which may be, for example, an input queue or a synchronous input node by which messages are input when they are sent by publishers, such as publishers 5,10 to the message broker. A published message is fetched from the input mechanism by a controller 40 and processed to determine, among other things, to which subscribers, for example, subscribers 60, 65, 70, the message should be sent.
The use of topics is a key to the delivery of messages from publishers to subscribers. When a subscriber registers, that subscriber must specify a delivery mechanism by which it wants to receive messages and must define the types of messages it wishes to receive; that is, the topics. A subscriber can, for example, specify that it wishes to receive messages including a topic string such as “employee/salary”. The broker uses a matching engine 30 to attempt to match a published message having a particular topic string with subscribers who have indicated they want to receive messages including that topic string. When a match is found, the message is forwarded to the subscriber via an output mechanism 50. While the drawing shows a message broker having only a single input mechanism and a single output mechanism to simplify the description, a message broker will typically support multiple input and output mechanisms.
It is common practice in publish/subscribe messaging environments to make use of a particular kind of topic, a status topic, in the message broker to retain data indicative of the availability of a pub/sub system or device. The term “device” should be construed as encompassing software applications running on hardware systems. The device availability data may be implemented as a “retained” publication, indicating the current status of a client. Client status is updated when a publish/subscribe client comes online and reports its status or when it goes offline.
While broker-maintained device availability data is useful in publisher/subscriber systems, such data has not been available to devices that do not implement a publisher/subscriber interface. A common example of a network device that has not been able to make use of publisher/subscriber device availability data is a network device operating in an IP (Internet Protocol) network.
IP devices typically attempt to discover the availability of other devices through the execution of a PING process. In a PING process, a first system attempts to discover the availability of a second system by sending several PING messages to the second system, that may be identified in the messages either by an alphanumeric domain name or numeric IP address. If the second system is capable of responding, it responds to each PING message. Each response echoes the second system's IP address and contains a response time value. If the second system is off-line or otherwise unreachable, PING process software in the first system will time out, indicating failure to reach the second system.
FIG. 2 is a graphical representation of a conventional PING operation performed in an IP network. An IP device 80 attempts to PING device identified by the alphanumeric domain name “A.mqtt.org”. In an IP network, messages are not sent directly to the device when the device has been identified only by its alphanumeric domain name. Device 80's request is sent to a local domain name server (DNS) 90 that attempts to resolve the “A.mqtt.org” domain name to a numeric IP address; e.g., 1.2.3.4. If the local domain name server is unable to resolve the domain name to an IP address, it directs device 80 to a remote domain name server 95 having assigned responsibility for the specified domain (e.g. mqtt.org). DNS 95 may resolve “A.mqtt.org” to a numeric IP address (e.g., 1.2.3.4) using an IP address mapping table and then inform device 80 of the numeric IP address to which the PING messages should be routed. When the PING messages reach device “A.mqtt.org”, that device will respond if it is online. Otherwise, the PING process at device 80 will time out, indicating A.mqtt.org is not reachable.
Publish/subscribe devices may be behind a company firewall and cannot be PINGed directly to determine their status. Further, some publish/subscribe devices can only be reached via a publish/subscribe mechanism on a network which does not include the ability to respond to PING requests (for example, a non-IP network).